There are many computing environments having multiple software applications that need to interact with each other and with other software such as libraries and runtime environments. There needs to be a mechanism to protect the applications and objects owned by the applications, while still allowing interaction. One protection mechanism is to execute each application (or bundle of applications) in its own execution context. Herein, this is referred to as “isolated execution contexts.”
Isolated execution contexts means that a first application cannot access objects of a second application (or the objects belonging to the system runtime environment) in another isolated execution context unless the second application (or system runtime environment) explicitly provides an interface for access to the data. However, access to the object is allowed to applications executing in the same isolated execution context the object was created in (the owning context). Isolated execution contexts may be enforced by a firewall. For example, the firewall enforces a set of rules to protect the object from unauthorized access.
To share data with applications in other isolated execution contexts, an application can provide a shareable interface object (SIO). Firewall rules allow a shareable interface object (SIO) to be accessed from another isolated execution context. In addition, any object can be passed as a parameter from an application in one isolated execution context to an application in another isolated execution context via an SIO without the firewall determining whether all rules to prevent unauthorized access to the parameter object in the second applications execution context are complied with. In other words, the firewall allows the parameter object to be passed based on the fact that the SIO is being used to pass the object. In addition to object ownership control, when an object is accessed, other language access controls may be enforced. For example, the Java language allows the programmer to designate an object to be restricted to access from within its own Java language package by declaring the class without the attribute tag “public”.
However, passing objects (including arrays) as parameters or return values in an SIO is often of limited value. Usable parameters or return values of SIOs may be limited to primitive values, global arrays, runtime environment entry point objects, and SIOs. The limitation is part of the intrinsic definition of an isolation execution context—the parameter objects themselves belong to the first application's isolation execution context and are therefore not accessible from the second application's isolation execution context. Typically, arrays (other than global arrays) cannot be passed from one isolated execution context to another. To share the elements of an array, a developer may be able to create a wrapper SIO with a “get” method to individually access each element. However, using such a wrapper has a severe performance impact because accessing all the elements of the array requires repeatedly invoking the “get” method and enduring the cost of going through the firewall each time.
Smart cards are an example platform in which an application programmer may wish to pass an object to another application in a different isolated execution context. A smart card is a card that may resemble a credit card and contains an embedded integrated circuit (IC). Some smart cards are used as a subscriber identity module (SIM) card inside of a cellular telephone. Smart cards are highly secure by design, and tampering with one results in the destruction of the information it contains. Smart cards typically have microprocessors and memory for secure processing and storage. There also exists technology similar to smart cards, but in form factors other than smart cards. Examples of such related technology are smart buttons and USB tokens. These other technologies may be used for similar functions as smart cards. USB tokens can be plugged directly into the USB port of a PC. Both smart buttons and USB tokens provide programming capabilities similar to smart cards and have tamper-resistance properties.
Therefore, it would be desirable to allow for secure yet high-performance sharing in a computing environment that uses isolated execution contexts or the like.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.